home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19950726-19950929 / 000130_news@columbia.edu_Wed Aug 9 12:31:37 1995.msg < prev    next >
Internet Message Format  |  1995-12-25  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA04916
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Thu, 10 Aug 1995 13:24:03 -0400
  3. Received: by apakabar.cc.columbia.edu id AA16184
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Thu, 10 Aug 1995 13:24:00 -0400
  5. Newsgroups: comp.protocols.kermit.misc
  6. Path: news.columbia.edu!news.cs.columbia.edu!news.boxhill.com!news.sprintlink.net!noc.netcom.net!netcom.com!mkercher
  7. From: mkercher@netcom.com (Matthew Kercher)
  8. Subject: Re: Packet length and file transfers
  9. Message-Id: <mkercherDD1Msp.pE@netcom.com>
  10. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  11. References: <3vrtpa$p0r@gold.tc.umn.edu> <4052aj$7cc@apakabar.cc.columbia.edu>
  12. Distribution: USA
  13. Date: Wed, 9 Aug 1995 12:31:37 GMT
  14. Lines: 30
  15. Sender: mkercher@netcom15.netcom.com
  16. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  17.  
  18. fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  19.  
  20. >In article <3vrtpa$p0r@gold.tc.umn.edu>,
  21. >Jim Scott <scott048@gold.tc.umn.edu> wrote:
  22. >: I've finally managed to get kermit to transfer files reliably and have 
  23. >: moved on to the next stage -- improving transfer performance.  I download 
  24. >: I've got my window slots set to 31, CTS flow control, 57600 speed with a 
  25. >: 
  26. >: 14.4 modem using compression and error correction.  My control prefixing 
  27. >: is limited to three characters.
  28. >: 
  29.  
  30. If I infer correctly that you are using MS-Kermit on a PC, you limitation may
  31. be hardware, not protocol strategy.  A lame 8250 or 16450 UART on a serial
  32. board or internal modem will loose characters on such high-speed, long packet
  33. receive transfers because it lacks adequate data buffering.  This causes
  34. multiple retries.  The longer your packet length, the more data that has
  35. to be resent in a bad packet, thus killing the throughput.  Keep an eye
  36. on the number of retries during file transfer to get a feel for the size of
  37. the bad packet/lost data problem.  Or go buy a good serial board with
  38. a 16550 UART.
  39.  
  40. -- 
  41.  Matt Kercher
  42.  San Francisco, Ca.
  43.  mkercher@netcom.com
  44. -- 
  45.  Matt Kercher
  46.  San Francisco, Ca.
  47.  mkercher@netcom.com